تالار های تخصصی

تمیز کردن پروژه'>پروژه های پیش فروش معتبر با پروزه های بی اعتبار متاسفانه باید بگویم که درصد بالایی از پروژه های پیش فروش در منطقه 22 تهران دریاچه چیتگر با نیت کلاهبرداری و سواستفاده از مردم تشکیل میشوند از این بابت در این مقاله به راهکار هایی که میتوان پروژه های معتبر راتا حدی از دیگر پروژه ها تفکیک کرد اشاره خواهیم کرد تا حدی به درصد آگاهی مردم نسبت به پروژه های پیش فروش تعاونی ساز و حتی شخصی ساز اضافه کنیم و هرچقدر آگاهی مردم نسبت به نوع تشکیلات سازنده ها و تعاونی ها ی پیش فروش در منطقه 22 تهران بالا برود میتونند انتخاب بهتری داشته و کمتر فریب کلاهبرداران را بخورند 1- اولین و مهم ترین نکته که شما پیش خرید آپارتمان در منطقه 22 تهران بایستی به آن توجه داشته باشید رزومه تعاونی مسکن سازنده میباشد . لطفا به مشاوره های مشاوران املاک و تیم فروش تعاونی ها بسنده نکنید و پروژه های مه بعنوان رزومه کاری معرفی میشود بصورت حضوری با هییت مدیره برج ها و حتی ساکنین برج های ساخته شده صحبت کنید و به این نکته توجه کنید در استعلام هاایی که انجام میدهید درباره اشخاص استعلام نکنید و صرفا نام تعاونی سازنده برای شما ملاک باشد. بارها دیده شده تعاونی های کلاهبردار با استخدام اشخاص تاثییر گذار در تعاونی های معتبر بصورتی اقدام به رزومه سازی برای خود میکنند اگر تعاونی مسکنی رزومه ندارذ شما با ورود به آن پروژه پیش فروش و امتیاز در حال قمار کردن با اموال و سرمایه خود هستید . نداشتن رزومه دلیل بر نساختن و کلاهبردار بودن تعاونی مسکن نیست اما درصد ریسک شما را به مراتب بالا میبرد 2- در هیچ صورت وارد پذیره نویسی و عضو گیری تعاونی هایی که جواز ساخت پروژه پیش فروششان  بصورت 100 درصد انجام نشده است نشوید . بسیار پ تالار های تخصصی...

در نسخه 23c، اوراکل پکیجی را به نام DBMS_SEARCH معرفی کرده است که می تواند با استفاده از زیرساخت ORACLE TEXT و حذف پیچیدگی های آن، امکان جستجو را بر روی Objectهای مختلف فراهم کند. پکیج DBMS_SEARCH با ایجاد ایندکسی از نوع JSON Search Index می تواند قابلیت جستجو را بر روی sourceهای مختلف اعم از Table و View فراهم کند. برخلاف ایندکسهای متعارف نظیر Btree و Bitmap که بر روی ستونهای یک جدول قابل ایجاد هستند، ایندکسی که از طریق پکیج DBMS_SEARCH ایجاد می شود، می تواند چندین جدول و ویو را به عنوان source بپذیرد و جستجوی همزمان را بر روی این sourceها انجام دهد. جداولی که به عنوان سورس تعیین می شوند می توانند حاوی ستونهایی با نوع داده number، varchar، CLOB، JSON و … باشند و محدودیتهای بسیاری کمی در این زمینه وجود دارد ضمنا اضافه کردن source به ایندکس به راحتی و صرفا با اجرای یک دستور امکان پذیر است. توجه! ایندکسهایی که از طریق این پکیج ایجاد می شوند، بروزرسانی آنها به صورت خودکار انجام می شود(sync on commit). در ادامه با نحوه ایجاد این نوع از ایندکس، اضافه کردن source به آن و همچنین انجام جستجو از طریق آن آشنا خواهیم شد. در ابتدا جداول و ویوهایی را ایجاد می کنیم تا بتوانیم از این جداول و ویو به عنوان sourceهای ایندکسی که از طریق DBMS_SEARCH ایجاد می کنیم، استفاده کنیم: SQL> create table IranTBL1(id number primary key,des varchar2(1000)); Table created. SQL> insert into IranTBL1 values(1,'www.usefzadeh.com'); 1 row created. SQL> create table IranTBL2(id number primary key,des1 varchar2(1000),des2 CLOB,des3 JSON); Table created. SQL> insert into IranTBL2 values(1,'My name i تالار های تخصصی...

تغییر Execution Plan یک کوئری می تواند به دلایل ساده ای مثل حذف و اضافه کردن ایندکس، پارتیشن بندی جدول، پارتیشن بندی ایندکس اتفاق بیفتد اما شناسایی علت تغییر رفتار Optimizer همیشه ساده نیست چرا که در بعضی از موارد تغییر در Optimizer Environment منجر به ایجاد Execution Plan جدید می شود. برای مثال در sessionای پارامتر OPTIMIZER_INDEX_COST_ADJ که میزان گرایش Optimizer به استفاده از ایندکس را تعیین می کند، به عدد 1 و در session دیگر این پارامتر به مقدار 1000! تنظیم شده است بدون تردید این تفاوت ها در Optimizer Environment، می تواند Execution Plan بعضی از کوئری ها را تغییر دهد. موضوع این مستند در مورد آن است که چگونه می توانیم تشخیص دهیم تغییر Execution Plan یک کوئری به دلیل تغییر در Optimizer Environment است؟ و به طور دقیق تر، کدام پارامترها و عوامل محیطی منجر به ایجاد Execution Plan جدید شده اند. این کار را با قابلیت جدیدی که اوراکل در نسخه 23c ارائه کرده است، انجام خواهیم داد. اوراکل در نسخه های قبل از 23c، در ویوهای V$SQL، V$SQLAREA و DBA_HIST_SQLSTAT در کنار Plan Hash Value مقداری را برای Optimizer-Environment Hash Value نگه می داشت ولی جزییات بیشتری را در مورد این ستون ارائه نمی کرد. اما در نسخه 23c، ویوی DBA_HIST_OPTIMIZER_ENV_DETAILS را ارائه شده است که در این زمینه بسیار راهگشا خواهد بود. نکته!با استفاده از ویوی v$sys_optimizer_env و v$sql_optimizer_env می توانیم Optimizer Environmentها را ببینیم. در ادامه قصد داریم از پارامتر OPTIMIZER_INDEX_COST_ADJ برای آشنایی بیشتر با ویوی DBA_HIST_OPTIMIZER_ENV_DETAILS استفاده کنیم. در ابتدا برای پیش بردن سناریو، جدول و ایندکسی را ای تالار های تخصصی...

اوراکل در نسخه 21c دیتاتایپ JSON را ارائه کرد و تا قبل از آن، دیتای JSON را می توانستیم در ستونهایی با نوع داده CLOB، BLOB و حتی VARCHAR ذخیره کنیم با این اوصاف اگر دیتابیس را به تازگی به نسخه 21c(و نسخ بالاتر) ارتقا دادیم ممکن است بخواهیم دیتای از نوع JSON را به ستونی که دیتاتایپ آن JSON است منتقل کنیم. در نسخه 23c، پروسیجری اضافه شده است که می تواند در این فرایند مورد استفاده قرار بگیرد و بعضا بسیار راهگشا باشد. پروسیجر dbms_json.json_type_convertible_check ستونی را به عنوان ورودی می گیرد و بررسی می کند همه فیلدهای آن ستون حاوی دیتای معتبر با فرمت JSON هستند و اگر در این بررسی خطایی رخ دهد این خطا از طریق جدول json_data_precheck قابل مشاهده است. در ادامه جدولی را ایجاد می کنیم که ستونی از نوع CLOB دارد قرار است دیتای JSON را در این ستون ذخیره کنیم البته محدودیت is json constraint check را برای این ستون تنظیم نمی کنیم تا در هنگام ذخیره کردن اطلاعات، دیتای نامعتبر هم در آن قابل درج باشد. SQL> create table author_tbl( 2 ID number generated always as identity, 3 author_desc clob 4 ); Table created SQL> insert into author_tbl(author_desc) values('{"NAME" : "Abbas Hamidian","GENDER" : "m","CURRENT_JOB" : "Oracle DBA"}'); 1 row inserted SQL> insert into author_tbl(author_desc) values('{Ali Fazli}'); 1 row inserted SQL> insert into author_tbl(author_desc) values('usefzadeh.com'); 1 row inserted SQL> commit; Commit complete قصد داریم اطلاعات ستون Author_Desc را به ستونی از نوع داده JSON منتقل کنیم(در اوراکل 23c). قبل از جابجایی دیتا، از طریق پروسیجر dbm تالار های تخصصی...

Table Values Constructor قابلیتی است که در بیشتر دیتابیسهای رابطه ای وجود داشته و اوراکل امکان استفاده از این قابلیت را در نسخه 23c فراهم کرده است. بر اساس این قابلیت، می توانیم با اجرای یک دستور insert ساده(Insert به همراه عبارت Values) چندین رکورد را در یک جدول درج کنیم البته استفاده از کلمه کلیدی Values به دستور insert محدود نمی شود و از این عبارت می توانیم برای دستورات DMLای دیگر نظیر Select و Merge هم استفاده کنیم. ابتدا مثالی از نحوه استفاده از این قابلیت را به همراه دستور insert مشاهده می کنید. SQL*Plus: Release 23.0.0.0.0 - Developer-Release on Tue Aug 29 22:41:17 2023 SQL> insert into Irani values(1,'Vahid'),(2,'Usef'); 2 rows created. SQL> commit; Commit complete. با اجرای دستور فوق دو رکورد در جدول Irani ثبت شده اند: SQL> select * from Irani; ID NAME ---------- -------------- 1 Vahid 2 Usef این کار در نسخه های قبلی اوراکل امکان پذیر نبود: SQL*Plus: Release 21.0.0.0.0 - Production on Tue Aug 29 21:47:30 2023 SQL> create table Irani(id number,name varchar2(14)); Table created. SQL> insert into Irani values(1,'Vahid'),(2,'Usef'); 'ORA-00933: SQL command not properly ended' و برای انجام این کار در نسخه 21c می بایست دو بار دستور insert را اجرا کنیم: SQL*Plus: Release 21.0.0.0.0 - Production on Tue Aug 29 21:47:30 2023 ID NAME ---------- ----- 1 Vahid 2 Usef SQL> insert into Irani values(1,'Vahid'); 1 row created. SQL> insert into Irani values(2,'Usef'); 1 row created. البته امکان اجرای دستورا تالار های تخصصی...

در نسخه 21c اگر در تراکنشی از Parallel DML استفاده کنیم، امکان گرفتن query و یا اجرای دستورات DML و یا Parallel DML بر روی همان جدول و در همان تراکنش از ما گرفته خواهد شد: SQL> alter session enable parallel dml; Session altered. SQL> insert /*+parallel(10)*/ into tbl1 select * from v$datafile; 1536 rows created. Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.8.0.0.0 SQL> select count(*) from tbl1; 'ORA-12838: cannot read/modify an object after modifying it in parallel' SQL> delete tbl1; 'ORA-12838: cannot read/modify an object after modifying it in parallel' با خاتمه دادن به تراکنش شاهد این خطا نخواهیم بود: SQL> commit; Commit complete. SQL> select count(*) from tbl1; COUNT(*) ---------- 6144 SQL> delete tbl1; 6144 rows deleted. در نسخه 23c این محدودیت برداشته شده و بدون بستن تراکنش می توانیم دستور فوق را اجرا کنیم: Oracle Database 23c Free Release 23.0.0.0.0 - Develop, Lea, and Run for Free Version 23.3.0.23.09 SQL> alter session enable parallel dml; Session altered. SQL> insert /*+parallel(10)*/ into tbl1 select * from v$datafile; 14 rows created. SQL> select count(*) from tbl1; COUNT(*) ---------- 28 SQL> delete tbl1; 28 rows deleted. وحید یوسف زادهارائه خدمات مشاوره ، پشتیبانی و نصب و راه اندازی پایگاه داده اوراکل در سراسر کشور...................... تلفن: 09128110897 ایمیل:[email protected] تالار های تخصصی...